Here, you will get answers to frequently asked questions (FAQs) about Identity Management (IdM) Framework v1.1.0 for use with STA. Answers to FAQs provide the most common information you need for using the IDM Framework.

The Identity Management Framework enables user and group provisioning between SafeNet Trusted Access and other third-party applications and directories. It utilizes an open-source identity management and governance platform, midPoint, underneath.

The solution uses dedicated identity connectors that connect to different directories, to automatically create, update, and remove users and groups.

Frequently Asked Questions

Q. What are the minimum system requirements to deploy IdM Framework on a machine?

Operating System requirements:
Click here to know the supported Operating systems details to deploy IdM Framework.

Hardware requirements:

Hardware	Minimal	Typical up to 5,000 users	Typical up to 50,000 users	Typical up to 100,000 users
CPU	1 core	4 cores	8 cores	16 cores
RAM	4GB	8GB	16GB	16GB
Disk space	2GB	10GB	20GB	40GB
Disk I/O	Negligible	Negligible	Negligible	Negligible

It is recommended to use Linux or UNIX systems.

This framework is not supported with SafeNet Authentication Service on premise (PCE/SPE) version.

Q. Which ports must be opened on the machine on which the IdM Framework will be deployed to communicate with STA?

The following ports need to be opened on the machine where IdM framework is deployed:

• LDAP – 636, 389
• HTTP - 8080
• HTTPS – 8443,443

Q. How to deploy the IdM Framework docker image?

Refer to the Deploying Identity Management Framework section for the steps to deploy IDM Framework as a docker container.

Q. How to stop or start the IdM Framework container?

Run the following commands:

• docker stop <container ID> to stop the container

• docker start <container ID> to start the container

If the machine has been brought down due to some reasons, after bringing it up, you may find that all the containers running on the machine are in the down state. To run the solution now, you need to start the PostgreSql container first, and then the IdM Framework container.

Q. Can I configure the AD connector to synchronize users or groups using a non-administrative user account?

Yes, you can. Also, it is recommended to use a delegated administrative privileged account to configure the AD connector to synchronize users or groups. You need to ensure that the account has the required set of permission as suggested in the Granting Access Rights to idmadmin section of Active Directory (AD) as Identity Source documentation on the Thales online documentation portal.

Q. How to rectify a certificate error while testing the connection of the connector?

In the IdM Framework keystore, add the whole certificate chain again for your connector (STA, AD, or Microsoft Entra ID) and restart the IdM Framework instance.

It might be possible that your system is protected by a proxy server. Ensure that you have the whole certificate chain of the connector or resource that is added to the IdM Framework keystore.

Q. Does IdM Framework support password synchronization?

No, IdM Framework does not support password synchronization as of now. After user provisioning, you need to manually configure the users' passwords.

Q. Does the IdM Management Framework solution support multi-domain server synchronization? If yes, up to what hierarchy?

Yes, it does support multi-domain server synchronization for Active Directory (AD) and Microsoft Entra ID (AD) connectors.

For Active Directory, the solution is tested with a single forest with one parent domain (for example, example.com), one child domain controller (for example, child.example.com), and a tree root domain (for example, testroot.com) as shown in the below image:

For queries related to multi-domain configuration, contact Thales Support.

Q. How can I configure multi-domain in AD using minimum configuration?

To configure multi-domain servers in the same AD connector, you need to edit your AD connector instance in Edit Raw mode and add the servers’ details in the .xml format.

For more information on multi-domain configuration, contact Thales Support.

Q. Does IdM Framework support bidirectional sync with all connectors?

Yes, IdM Framework provides bidirectional synchronization support for AD and Microsoft Entra ID Directory services. You can configure bidirectional synchronization as per your preferred configuration by updating Inbound and Outbound mapping on the Schema handling tab of the respective connector. For support on bidirectional synchronization, contact Thales Support.

Q. How can I access the IdM Framework logs for troubleshooting?

You can access the following IdM Framework logs:

• Docker logs: These logs contain information on the IdM Framework containers. Run the following command to view docker logs:

  docker logs <container ID>

• IdM Framework Detailed logs: These logs are available in the midpoint.log file of the IdM Framework container. This is the primary log file and it records almost all the log messages. The log messages are set on several log levels from FATAL to INFO.

  To obtain the log file, first, you need to run the following command to enter in the container:

  docker exec -it <container ID> bash

  Then, go to /opt/midpoint/var/log folder and run the following command to access the midpoint.log file:

  cat midpoint.log

Q. What steps should I take if the Intent status is displayed as “unknown” for the AD or Microsoft Entra ID connector users?

The Intent status is displayed as “unknown” because of the synchronization configuration of the connector. For your AD or Microsoft Entra connector, you need to remove the group filtering conditions and then reconfigure it.

For the AD connector, perform the following steps to remove the group filtering conditions:

1. On the Synchronization page, under Edit ‘Account’, click on the Condition icon .

2. Under Edit synchronization condition, in the Expression field, remove the group filtering script conditions.

   

3. Click Update Expression and click Save.

   

After removing the condition, you need to reconfigure the connector using the scripts available in the package as suggested in the Capabilities section of the Active Directory (AD) as Identity Source.

Similarly, for the Microsoft Entra connector, you can remove the group filtering condition and reconfigure it as suggested in the Capabilities section of Microsoft Entra ID as Identity Source.

Q. Can I filter the users or groups before sending them to STA? How do the users or groups get filtered?

Group Filtering is completely supported for the AD connector and partially supported for Microsoft Entra connector.

For Microsoft Entra ID, during configuration, task execution for users is not supported when it is used with the user filtering script in the synchronization condition.

Workaround:

• Use case 1
  If all the users and groups in Microsoft Entra ID need synchronization with STA, then there is no need to use the filtering scripts for users and groups. In this case, the import tasks will work as expected.

• Use case 2
  If a subset of users and groups in Microsoft Entra ID needs synchronization with STA, you need to use filtering scripts for user and group filtration. The task execution will not work in this scenario and you need to manually perform any action for such users or groups.

Currently, IdM Framework doesn’t provide any user interface to select the groups for synchronization with STA. You can add the required groups into the groupName array list to get them synced into STA, as shown in the below screenshot.

For more details on how to filter the groups and users before sending them to STA, follow the following documentation on the Thales online documentation portal:

• For Group filtering in Active Directory, refer to the Capabilities section of the Active Directory (AD) as Identity Source documentation.

• For Group filtering in Microsoft Entra ID, refer to the Capabilities section of the Microsoft Entra ID as Identity Source documentation.

Q. How long does it take to reflect user deletion in STA after the users are deleted from the identity source such as AD or Microsoft Entra ID?

By default, users are deleted after 24 hours in STA when removed from the identity sources like AD or Microsoft Entra ID.

To remove users instantly, go to the SAS console, and navigate to Comms > Authentication Processing > LDAP Sync Agent Settings to enable/disable this setting. Ensure that you have disabled the “Use Delayed Sync Removal” option in STA. By default, this option delays the removal of synchronized user records flagged for deletion from STA for 24 hours. Conversely, if this option is disabled, user records are deleted with all user/token associations immediately and permanently from STA upon synchronization.

Q. Does the solution validate the user accounts state before syncing to STA?

Currently, it does not validate whether the user account state is active, inactive, or locked before synchronizing to STA.

Q. Can I stop the user synchronization in IdM Framework for a particular period (I may need this when the system goes in maintenance mode)?

Yes, you can stop user synchronization by putting the resource or connectors in maintenance mode. Perform the following steps to put a resource in maintenance mode:

1. On the IdM Framework administrator console, in the left pane, click Resource *All resources*.

2. In the right pane, select the appropriate connector resource, click on the icon, and select Toggle maintenance.

Q. What is the behavior when a user gets deleted from IdM Framework?

IdM Framework can be treated as the central repository. By default, the delete capability is disabled in all the resources. So, when a user gets deleted, the user will not be deleted from any of the resources.

However, the delete settings can also be configured as per your preferred configuration, like, the user can be deleted from all the resources or any specified resource.

If you want the user account to get deleted from all the resources, delete the account in IdM Framework and ensure that in the Capabilities tab > Delete section, the Delete capability is configured as Enabled. 

 

As a best practice, the Delete capability should be disabled to avoid any accidental deletion from all identity sources.